Deployment of network devices such as residential gateways, routers, cable modems, and other devices presents problems with respect to initial registration, configuration, and bootstrapping of the devices in a distributed network. Network service providers and their customers desire to have a way to rapidly deploy numerous network devices with minimal pre-configuration, and to have a way to efficiently register the devices in the network once they are deployed, with minimal customer involvement. For example, in large packet cable networks that include consumer-grade cable modems, there is a need to deploy the devices rapidly and register them in the network upon installation at the customer premises, without requiring the customer to have technical knowledge or carry out complicated registration steps.
A related problem, in this context, involves how to securely register a device so that only authorized devices are registered in the network. There is a specific need for a reliable and secure way to positively identify a newly deployed device as authorized to register in the network. Thus, there is a need for a rapid, efficient, and simple way to establish a secure communication channel between a newly deployed network device and the network itself.
A more specific problem in this context relates to password management. While it is desirable to have a communication channel between the newly deployed network device and the network that is secured using encryption, it is undesirable to require the customer to enter a password or manage the updating and use of passwords. Distribution of passwords, in particular, is troublesome. It is also impractical to require the customer to manage policy issues such as when passwords or keys expire, scheduling distribution of replacement keys, or configuration of new keys for new services provided to an existing network device. Therefore, there is a need for a scalable approach for distribution of new passwords or keys to network devices that are deployed in a distributed network.
In a distributed network that uses secure communications, network nodes that initiate or manage the secure communications are termed “principals.” Such security principals may be software processes, computers, elements of network infrastructure, etc. Achieving secure communications among principals in a distributed network requires a process of key management and distribution, and the ability to associate a key with a principal. Two primary technologies may be used to accomplish these objectives: public key (or asymmetric key) technology and symmetric key (or shared key) technology. Typically, these systems are associated with security infrastructure elements based on digital certificates that are generated based on exchanges of public keys (a “public key infrastructure” or “PKI”), or based on a Kerberos infrastructure. Each of these systems had distinct disadvantages. It would be desirable to have a system that could leverage their strengths while mitigating their weaknesses.
In general, a trusted third party can provide a mechanism for scalable trust management within a network security system. Both public key certificate-based systems and Kerberos-based systems use a trusted third party. In particular, a PKI requires trust in a Certification Authority (CA), and Kerberos requires trust in a Key Distribution Center (KDC). In either case, compromise of the trusted third party is catastrophic to the security infrastructure.
However, CAs and KDCs are ideologically different. In PKI, only the user is supposed to know the user's private key. Ideally, in a PKI transaction, there is no online third party involved; authentication is performed end to end. Additionally, store and forward types of applications can take advantage of the fact that an online third party is not required for authentication. Kerberos, however, assumes that the trusted authority is always online.
Both a CA and a KDC have a single point of failure in the form of a master key. For a CA, the master key is the private key used for signing certificates. For the KDC, the master key is the symmetric key used for encrypting the principal database. If a CA is compromised, then an attacker may impersonate a user by signing his own certificate with the compromised key. If a KDC is compromised, then the attacker may impersonate a user within the KDC's realm by using that user's symmetric key that was stored in the principal database.
A PKI uses asymmetric or public key cryptography for identity management. The term “asymmetric” is used, because of the application of two inverse keys comprising a public and a private key. These keys are termed inverse because one key is used to decrypt what the other key encrypts. In contrast, with a symmetric or shared key, the same key is used for encryption and decryption. A public key is a key that is publicly known. A private key is known to only one individual, in contrast to a secret key, which is shared. Further more information on symmetric and asymmetric cryptography appears in B. Schneier, “Applied Cryptography” (New York: John Wiley & Sons, 2d ed. 1996). A brief overview of pertinent concepts is provided herein.
A PKI establishes the identity of a principal by binding the name of the principal to a public key. In this context, the name of a principal may be a distinguished name (“DN”) as defined in the International Telecommunications Union (ITU) X.500 standard. This binding occurs in a data construct called a certificate. Since there is only one private key associated with a public key, and that private key is known to only one entity, certain important operations may be carried out based on an assurance that the public key is bound to a particular principal. For example, a principal can authenticate itself by proving knowledge of the private key associated with the public key, for example, by encrypting something that can be verified by the public key. The encrypted information is known as a digital signature, and it can be created because the private key is known to only the principal whose DN is bound in the certificate. Furthermore, a confidential message can be sent to a principal by encrypting the message in the public key found in that principal's certificate. Only the bearer of the associated private key may then decrypt the message.
However, an open issue with public key certificates is how one can know that a certificate is valid. For example, assume that A presents a certificate that contains person B's name associated with A's public key. This would allow A to impersonate B, which is a compromise of security. Use of a CA can address this concern because the CA is the trusted entity in a PKI that binds a name to a public key. When a certificate is issued by the CA, a user may trust that a public key is associated with the correct name of the principal that bears the corresponding private key. The CA digitally signs the certificate to indicate authenticity.
A registration authority (RA) may be involved in the certificate issuance and management process. Typically, an RA is used to improve certificate distribution; for example, it submits requests to the CA. As a specific example, a CA may be run as an outsourced service, with an RA at the consumer premises and having a trust relationship with the remote CA.
Registration of a principal is critical in establishing trust in the resulting certificate. Usually, this is performed by issuing a password, out of band, to a principal that uses the password to register for a certificate.
A remaining issue is how to trust the signature of the CA. Such a signature can be verified by checking the signature against the public key certificate of the CA. However, this process can result an infinite regress in which a party is required to continuously follow a chain of certificates. The issue is addressed by providing a root certification authority that is absolutely trusted. Certificates of the root certification authority are not signed by another CA. An example of a certificate chain is as follows: Suppose that V Company issues a certificate to M Company, which then issues a certificate to a software vendor. This vendor issues a certificate to an application plug-in developer. When a user wishes to install a plug-in into the application that runs on M Company's platform, the user verifies the authenticity of the plug-in by “walking” the certificate chain of the certificate associated with the plug-in. Of course, this can be a problem if an attacker has tricked V Company into issuing a certificate with M Company's name in it.
Still another issue is how to revoke certificates, such as those that have been compromised or inadvertently, for example. In one approach, each certificate is checked by querying a revocation server over a network. In a PKI, a certificate revocation list (“CRL”) is provided to enable a system to determine whether a certificate has been revoked.
FIG. 1 is a diagram of a public key infrastructure that uses digital certificates that conform to the ITU X.509 standard and protocols. Client 102 is seeking to communicate using a secure connection 104 to an end service 106; both client 102 and end service 106 are security principals, and must obtain a public key certificate. In one approach, client 102 issues a certificate request 108A to certification authority 110. End service 106 may similarly issue a certificate request 108B to the CA 110. Alternatively, client 102 and end service 106 may respectively issue certificate requests to a registration authority 112, which passes the requests to CA 110 in a pre-defined way. CA 110 may consult directory 114 to obtain or verify DN's of client 102 and end service 106.
Two principals may authenticate and establish secure communications using their public key certificates. For example, the Secure Sockets Layer (SSL) protocol or TLS protocol may be used to authenticate and establish a shared session key that can be used to communicate establish an encrypted channel. Because of the computational burden of carrying out public key exchanges, public key exchange techniques generally are used only to establish a shared, symmetric key, rather for direct encryption of a secure channel. In order to assure that the other principal is trusted, each principal must verify the other's certificate against a CRL, which may be obtained from a directory server 114 (as indicated by CRL 116A, CRL 116B), from CA 110 (as shown by CRL 116C), or through an online revocation service.
FIG. 2 is a diagram of an example Kerberos key management system. Kerberos defines a protocol for authentication and key transport in which a trusted key distribution center (“KDC”) 200 issues symmetric key based certificates (“Kerberos tickets”) for the purpose of authentication and key establishment. Kerberos principals, such as client 102 and end service 106, share a key with the KDC 200. The KDC 200 is then able to communicate securely with any of its principals. A ticket contains a symmetric key that is encrypted under the key shared by a principal and the KDC 200. It binds the name of the requestor or client to the key; the recipient or server is implied, since the server's key encrypts the ticket. Therefore, the client and server principals can authenticate by proving knowledge of the key contained within the ticket. A Kerberos “administrative realm” defines a trust boundary. Kerberos is further described in J. Kohl and C. Neuman, “The Kerberos Network Authentication Service (V5)”, RFC 1510, September 1993, and “Kerberos: An Authentication Service for Computer Networks”, B. C. Neuman, T. Ts'o, IEEE Communications, 32(9):33–38, September 1994.
In the Kerberos protocol, several data exchanges are carried out, as shown in FIG. 2. First, an initial authentication server exchange 201 is carried out when the client 102 initially authenticates to the KDC 200. Client 102 issues a request 204 for authentication. This authentication may be based on a password (converted to a key), a token card, a public key signature, or some combination of these or other mechanisms. The KDC returns a service ticket 206 for either the KDC's ticket-granting server, which is described in the next paragraph, or for an application service.
Second, a ticket granting server exchange 202 is carried out. A ticket granting service (TGS) is a logical construct within the KDC 200 that enables the KDC to issue application service tickets without having to require initial authentication from the client 102. The client 102 authenticates to the TGS by using service ticket 206, as indicated by TGS request 208. The TGS then issues a ticket 212 to the client for an application service.
Third, an application exchange 203 is carried out. Client 102 may use its application service ticket 212 to go directly to the application service 106 without contacting the KDC, as indicated by request 214. Client 102 may do so for the lifetime of the ticket 212.
An X.509 public key infrastructure is beneficial in that it uses digital signatures, and is well suited for store-and-forward applications. It also provides direct, end-to-end authentication without requiring an online trusted third party at the time authentication is carried out. However, PKI schemes also have significant disadvantages. For example, complicated administration issues exist. Creation and distribution of key pairs is not trivial, and managing certificate lifetimes is not simple. A PKI may have varying policies for how long old certificates are honored; this may imply that a user will have a key for signing and a shorter-lived key for authentication and encryption, which adds a layer of complexity. Management of certificate revocation lists must be addressed, possibly requiring an online server.
Still other issues relate to how to provide secure storage of private keys. Use of smart cards or token cards, locally encrypted storage, a directory server, or removable media may be required, and there is no industry agreement on the foregoing. Computational efficiency of public key operations is a significant issue, as it is widely known that for keys of comparable strength, public key operations are on the order of 1,000 times slower than conventional symmetric key encryption operations.
Yet another challenge is state management. Public key network communications protocols, such as SSL and IKE, require both clients and servers to maintain state. The problem of following certification chains, in which a root certificate authority is absolutely trusted, is not entirely satisfactory. There are no well agreed-upon, deployed ways to carry out distributed certificate-related policies, such as authorization information. If the certificate contains authorization information, then there may be issues with re-issuing keys, re-certifying public keys, and revoking certificates Kerberos has the advantage of offering central administration of principals, and it is known to be scalable via replication. Further, Kerberos tickets can carry authorization information, have an assignable lifetime, provide a mechanism to maintain state (security context) in a sessionless protocol, without placing a burden on the server, and use short-lived credentials. However, Kerberos also has certain clear disadvantages. In general, it is known as best suited for use in the Intranet context rather than for securing Internet traffic. It requires a central, online third party for authentication; a client cannot access the end service if the KDC is busy, down or unavailable. It requires a database of shared secrets, which may introduce scalability issues as the database grows in size. Replication of such databases to multiple distributed locations is complex and error-prone. It does not provide digital signatures or a mechanism for non-repudiation of communications. Cross-realm authentication is complicated to carry out.
An X.509 PKI has the advantage of widespread acceptance in Internet applications, and the ready availability of commercial X.509 solutions and trusted CAs. An advantage of Kerberos is that it is supported by products of Microsoft Corporation, such as in the Windows 2000 operating system, which has gained wide acceptance in the enterprise computing market. However, a weakness of Kerberos is a lack of acceptance outside the Microsoft environment, and the existence of relatively few commercial grade implementations.
Thus, there is a need for a way to provide secure key distribution in a manner that offers interoperability among different systems and high performance. There is a need for a system that has greater scalability than a Kerberos system and less administrative costs than a PKI system. There is also a need for a system that is equally useful for inter-network communication and intra-network communication.
Based on the foregoing, there is a clear need for an improved method to distribute keys for use in establishing secure communications that achieves the advantages set forth above without the disadvantages described above.
Further, to provide a registration and bootstrap mechanism that is highly automated, there is a need for a way to authenticate a device and registration service. Because this in turn requires a way to carry out initial authentication, a form of keying is needed, and as a result there is a need to minimize the amount of effort to do such initial staging.
There is also a need to be able to deploy devices in a distributed fashion; while the attributes of a public key system can be used, there is also a need to mange devices centrally, and therefore there is a need to use an approach having the attributes of Kerberos.
There is also a need for a system that does not require propagation of large databases of keys, for example, using enhancements to Kerberos. There is a need to either eliminate or minimize the amount of data that is propagated, without placing fixed keys on devices. There is also a need for a way to apply a centralized policy to carry out key schedule.
There is still a further need for a way to have consistency in the security infrastructure that is used for managing the devices, so that the same security infrastructure can be applied to later uses.